本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。

關於資源評估

架構團隊提供虛擬機給應用，有個問題時常出現：應該分配多少資源給應用？例如：後端準備一個 API server，SRE 這邊要準備多少什麼規格的機器？

以往使用虛擬機直接部署應用時，會需要明確規劃各群虛擬機，各自需要執行的應用，如果沒有做資源的事前評估，有可能放上機器運行後就發生資源不足。

導入 Kubernetes 後，透過節點池 (Node Pool) 形成一個大型資源池，設定部署的政策後，讓 Kubernetes 自動調度應用：

• 每一個節點的資源夠大，使得應用虛擬機器上所佔的比例相對較小，也就是單一應用的調度不會影響節點的整體負載
  • 如果節點太小，調度應用就會有些侷促，例如：一個 API server 均載時消耗 1 cpu 滿載時消耗 2 cpu。準備 3 cpu 的虛擬機，調度應用時幾乎是遷移整台虛擬機的負載
  • 此外還有機會因為上篇提到的資源保留，造成調度失敗。如果準備 24 cpu 的機器，調度起來彈性就很大，對節點的性能衝擊也比較低
• 只需要估計整體的資源消耗率計算需求，配合自動擴展，動態器補足不足的資源
  • 例如：估計總共需要 32 cpu ，準備 36 cpu 的虛擬機，當滿載時依據 cpu 壓力自動擴容到 48 cpu
• 希望整體資源的使用率夠高，當然預留太多的資源會造成浪費

要控管 Kubernetes 的資源使用量也可設定資源需求與資源限制，延伸閱讀。

估計得越準確，當然實際部署的資源掌握度就越高，然而筆者過去的經驗，團隊在交付源碼時未必就能夠做出有效的資源消耗評估，那有沒有什麼辦法可以幫助我們？

資源需求估估看

如果應用開發團隊，有先作應用的 profiling，然後 release candidate 版本有在 staging 上作壓力測試的話，維運團隊這邊應該就取得的數據，做部署前的資源評估。

應用在不同狀態或是工作階段，會消耗不同的資源

例如：運算密集的 batch job 可能會有

• 控制節點 (master node) 啟動後會佔有一定的資源，一般來說不會消耗太多，只是需要為控制節點優先保留資源
• 工作節點 (worker node) 啟動時會需要預留足夠的資源，接收工作後會逐漸增加資源使用，拉到滿載

例如：面向用戶的服務，可能會有

• 啟動應用所需的資源
• 沒有大量請求，只維持基本應用運行所使用的資源
• 負載壓力灌進來時，消耗資源隨用戶請求數量的成長曲線，設定的安全上界

如果沒有這些數據，其實維運很難事前估計資源，變成要實際推上線後見招拆招，基於實際的資源消耗去做自動擴容，其實有可能會造成資源的浪費，因此我建議如果開發團隊沒有作 profiling，維運團隊可以在工作流程內簡單加一
步 profiling，目前主流語言都有提供相關工具，簡單的執行就可以獲得很多資訊。

至於壓力測試，也是可以使用基本的工具(例如 Artilery)簡單整到工作流程。特別是面對客戶的應用，務必要進行壓力測試。

有了上述的資源需求數據，才能事先安排機器的規格。例如

• 應用是面對客戶的 API server
• 基本資源是 200m cpu 1Gi memory，這部分直接寫進 Kubernetes resource request，在排程時就先結點上預留。
• 負載拉到 1,000 RPS，latency 95% 20ms 99% 30ms，這時的資源需求的上界大約 2 cpu 4 Gi memory
• 超過 1,000 RPS 就應該要透過水平擴展去增加更多 instamce

如果單跑這個 API server，就可以安排 memory 8，cpu 4 的 GKE node-pool，讓負載落在可用資源的 60%-70%，這樣還有餘裕可以承受大流量，給自動水平擴展做動的時間。

資源調整參考

當然這些數據都可以依照時實際需求調整，資源要壓縮得更緊或更鬆都是可行的。

如果應用有整合分析後台，例如 Real-time Uer Monitoring、或是基本的 Google Analytics，都可以觀察這些調整實際對用戶帶來的影響，用戶行為改變對公司營收的影響，全都可以量化。例如

• 機器負載拉到 80%，cpu 的壓力，導致 API latency 增加到 95% 50ms 99% 100ms
• 此時用戶已經很有感了，會導致 0.1% 用戶跳轉離開
• 而這 0.1% 的用戶，以往的平均消費，換算成為公司營收，是 $1,000/month
• 把機器負載壓到 60%，只計算 cpu 的數量的話，需要多開 3 台 n1-standard-4 機器，共計 $337.26/month
• 提供老闆做參考，老闆可能會趨向加開機器

當然上面的例子都非常簡化，變成國中數學問題，這邊只是提供一個估算的例子。現實中的問題都會複雜百倍，例如機器規格拉上去出現新的瓶頸、例如依賴的服務，message queue、database 壓力上升，或是公司內部問題，就拿不
到預算(血淚 SRE)。如果要減少機器，也可以參考，一般來說聽到關機器省錢的話，老闆都會接受的 XD。

回到先占機器

根據上面的國中數學，把應用一個一個都計算清楚，需求逐漸明確了。假設，架構團隊拿到開機器的工單，掐指一算，決定

• 1 GKE cluster
• 6 n1-standard-4

這些都是隨選虛擬機，價格大約是 $747/month (含集群管理費 $73/month)。今天有人腦動大開，那如果全部換成先占節點呢？變成 $265/month，虛擬機費用 $192 / $674 = 0.28 直接打超過三折。

有人就擔心，這樣真的可以嗎？真的沒問題嗎？會不會影響用戶阿。

答案是會，就是會影響用戶 XD

聽到這邊很多人就怕了。但是怎麼個影響法呢，還需要看底下幾個段落，如果換成先占虛擬機，用戶會怎麼受到影響。我們也要試圖量化這個影響，當作要不要導入的判斷依據。

句個反例，「我覺得可以」「你覺得不行」，或是「某某公司的某某團隊可以啊」「我們公司也來做吧」，這些都是很糟糕的理由。除了對內部毫無說服力之外，也沒有辦法作為導入成效的指標，會讓團隊陷入「導入了也不知道有比
導入前好？」或是「具體導入後成效量化」，會影響團隊做出真正有效的判斷，應極力避免。

此外，問行不行之前，其實需要知道團隊願意為了三折機器，付出多少成本。如果只是每月省個台幣 15,000，工程師薪水都超過了。但如果手下有三十台或三百台以上，也許就非常值得投資。成本不是絕對的，很多時候要與其他成>本 (e.g. 開發人力時間成本) 一起考量。

以上幾篇文章都是說明導入的動機，明天開始說明先占虛擬機的各種機制，以及對應用的實際影響。

有寫過鐵人賽的都知道 30 篇真的很漫長，一篇文章幾千字，都要花好幾個小時。我去年後半，真的都會看讀者的留言跟按讚，取暖一波，才有動力繼續寫。留言的人多就會多寫，留言的人少就會少寫，各位覺得文章還看得下去，請務必來我粉專按讚留個言，不管是推推、鞭鞭、或是有想看的文章來許願，都十分歡迎。有你們的支持，我才有動力繼續寫。

請大家務必以實際行動支持好文章，不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然，沒人留言我就會當作自己才是垃圾文 (自知之明XD)，就會收一收回家嚕貓睡覺，掰掰~

我的粉專，等你來留言